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Abstract 


The Interactive Connectivity Establishment (ICE) protocol describes a Network Address 
Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the 
Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) 
defines a mechanism that allows ICE Agents to shorten session establishment delays by making 
the candidate gathering and connectivity checking phases of ICE non-blocking and by executing 
them in parallel. 


This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). 
The document also defines a new SIP Info Package to support this usage together with the 
corresponding media type. Additionally, a new Session Description Protocol (SDP) "end-of- 
candidates" attribute and a new SIP option tag "trickle-ice" are defined. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8840. 
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1. Introduction 


The Interactive Connectivity Establishment (ICE) protocol [RFC8445] describes a mechanism for 
Network Address Translator (NAT) traversal that consists of three main phases. 


During the first phase, an agent gathers a set of candidate transport addresses (source IP, port, 
and transport protocol). This is followed by a second phase where these candidates are sent to a 
remote agent within the Session Description Protocol (SDP) body of a SIP message. At the remote 
agent, the gathering procedure is repeated and candidates are sent to the first agent. Once the 
candidate information is available, a third phase starts in parallel where connectivity between 
all candidates in both sets is checked (connectivity checks). Once these phases have been 
completed, and only then, both agents can begin communication. 


According to [RFC8445], the three phases above happen consecutively, in a blocking way, which 
can introduce undesirable setup delay during session establishment. The Trickle ICE extension 
[RFC8838] defines generic semantics required for these ICE phases to happen in a parallel, non- 
blocking way and hence speeds up session establishment. 


This specification defines a usage of Trickle ICE with the Session Initiation Protocol (SIP) 
[RFC3261]. It describes how ICE candidates are to be exchanged incrementally using SIP INFO 
requests [RFC6086] and how the Half Trickle and Full Trickle modes defined in [RFC8838] are to 
be used by SIP User Agents (UAs) depending on their expectations for support of Trickle ICE by a 
remote agent. 


This document defines a new Info Package as specified in [RFC6086] for use with Trickle ICE 
together with the corresponding media type, SDP attribute, and SIP option tag. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


This specification makes use of terminology defined by the ICE protocol in [RFC8445] and by its 
Trickle ICE extension in [RFC8838]. It is assumed that the reader is familiar with the terminology 
from both documents. 


[RFC8445] also describes how ICE makes use of the Session Traversal Utilities for NAT (STUN) 
protocol [RFC5389] and its extension Traversal Using Relays around NAT (TURN) [RFC5766]. 
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3. Protocol Overview 


When using ICE for SIP according to [RFC8839], the ICE candidates are exchanged solely via SDP 
Offer/Answer as per [RFC3264]. This specification defines an additional mechanism where 
candidates can be exchanged using SIP INFO messages and a newly defined Info Package 
[RFC6086]. This also allows ICE candidates to be sent in parallel to an ongoing Offer/Answer 
negotiation and/or after the completion of the Offer/Answer negotiation. 


Typically, in cases where Trickle ICE is fully supported, the Offerer sends an INVITE request 
containing a subset of candidates. Once an early dialog is established, the Offerer can continue 
sending candidates in INFO requests within that dialog. 


Similarly, an Answerer can send ICE candidates using INFO requests within the dialog 
established by its 18x provisional response. Figure 1 shows such a sample exchange: 


STUN/TURN STUN/ TURN 
Servers Alice Bob Servers 
| 
STUN Bi.Req. INVITE (Offer) | 
= ‘ns co! ERE. 1 1 1 1 


| 
TURN Alloc Req | 


--------------- >| 


| 
| 
| 
| STUN Bi.Resp. 


| Eeieieemeoseese > 


SS SSS Edited EAE 


| 

| 183 (Answer) 

| 

| INFO/OK (SRFLX Cand.) 


| 

| 

| 

| 

| | 

200 OK | | 

Mos ne gp Da dE | | 
ACK | | 
Pa TT | | 
|<===== MEDIA FLOWS =====>| | 
| | 


Note: "SRFLX" denotes server-reflexive candidates 


Figure 1: Sample Trickle ICE Scenario with SIP 


3.1. Discovery Issues 


In order to benefit from Trickle ICE's full potential and reduce session establishment latency to a 
minimum, Trickle ICE Agents need to generate SDP Offers and Answers that contain incomplete 
and potentially empty sets of candidates. Such Offers and Answers can only be handled 
meaningfully by agents that actually support incremental candidate provisioning, which implies 
the need to confirm such support before using it. 
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Contrary to other protocols, where "in advance" capability discovery is widely implemented, the 
mechanisms that allow this for SIP (i.e., a combination of UA capabilities [RFC3840] and Globally 
Routable User Agent URIs (GRUUs) [RFC5627]) have only seen low levels of adoption. This 
presents an issue for Trickle ICE implementations as SIP UAs do not have an obvious means of 
verifying that their peer will support incremental candidate provisioning. 


The Half Trickle mode of operation defined in the Trickle ICE specification [RFC8838] provides 
one way around this, by requiring the first Offer to contain a complete set of local ICE candidates 
and using only incremental provisioning of remote candidates for the rest of the session. 


While using Half Trickle does provide a working solution, it also comes at the price of increased 
latency. Therefore, Section 5 makes several alternative suggestions that enable SIP UAs to engage 
in Full Trickle right from their first Offer: Section 5.1 discusses the use of online provisioning as a 
means of allowing the use of Trickle ICE for all endpoints in controlled environments. Section 5.2 
describes anticipatory discovery for implementations that actually do support GRUU and UA 
capabilities, and Section 5.3 discusses the implementation and use of Half Trickle by SIP UAs 
where none of the above are an option. 


3.2. Relationship with the Offer/Answer Model 


From the perspective of SIP middleboxes and proxies, the Offer/Answer exchange for Trickle ICE 
looks partly similar to the Offer/Answer exchange for regular ICE for SIP [RFC8839]. However, in 
order to have the full picture of the candidate exchange, the newly introduced INFO messages 
need to be considered as well. 
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4------------------------------- + +------------------------------- + 
| Alice dicicxocatotubronrsiercye ae p Weeeesesscssse- * Bob | 
| | Offer/Answer | | | | Offer/Answer | | 
| +-------- * | Module Lod Module | 4-------- * | 
| qd BE | ee eS ponerse oec + | ICE || 
| | Module | | I | | Module | | 
Ee + | || | ee + 
+------------------------------- + +------------------------------- + 


Figure 2: Distinguishing between Trickle ICE and Traditional Signaling 


From an architectural viewpoint, as displayed in Figure 2, exchanging candidates through SIP 
INFO requests could be represented as signaling between ICE modules and not between Offer/ 
Answer modules of SIP UAs. Then, such INFO requests do not impact the state of the Offer/ 
Answer transaction other than providing additional candidates. Consequently, INFO requests are 
not considered Offers or Answers. Nevertheless, candidates that have been exchanged using 
INFO requests SHALL be included in subsequent Offers or Answers. The version number in the 
"o=" line of that subsequent Offer needs to be incremented by 1 per the rules in [RFC3264]. 


4. Incremental Signaling of ICE Candidates 


Trickle ICE Agents will exchange ICE descriptions compliant to [RFC8838] via Offer/Answer 
procedures and/or INFO request bodies. This requires the following SIP-specific extensions: 


1. Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag 
"trickle-ice" in a SIP Supported: header field within all SIP INVITE requests and responses. 

2. Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option "trickle" 
within all SDP Offers and Answers in accordance to [RFC8838]. 

3. Trickle ICE Agents MAY include any number of ICE candidates, i.e., from zero to the complete 
set of candidates, in their initial Offer or Answer. If the complete candidate set is already 
included in the initial Offer, it is called Half Trickle. 
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4. Trickle ICE Agents MAY exchange additional ICE candidates using INFO requests within an 
existing INVITE dialog usage (including an early dialog) as specified in [RFC6086]. The INFO 
requests carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be prepared to receive 
INFO requests within that same dialog usage, containing additional candidates and/or an 
indication that trickling of such candidates has ended. 

5. Trickle ICE Agents MAY exchange additional ICE candidates before the Answerer has sent the 
Answer provided that an invite dialog usage is established at both Trickle ICE Agents. Note 
that in case of forking, multiple early dialogs may exist. 


The following sections provide further details on how Trickle ICE Agents perform the initial 
Offer/Answer exchange (Section 4.1), perform subsequent Offer/Answer exchanges (Section 4.2), 
and establish the INVITE dialog usage (Section 4.3) such that they can incrementally trickle 
candidates (Section 4.4). 


4.1. Initial Offer/Answer Exchange 
4.1.1. Sending the Initial Offer 


If the Offerer includes candidates in its initial Offer, it MUST encode these candidates as specified 
in [RFC8839]. 


If the Offerer wants to send its initial Offer before knowing any candidate for one or more media 
descriptions, it MUST set the port to the default value '9' for these media descriptions. If the 
Offerer does not want to include the host IP address in the corresponding "c-"line, e.g., due to 
privacy reasons, it SHOULD include a default address in the "c-"line, which is set to the IPv4 
address 0.0.0.0 or to the IPv6 equivalent ::. 


In this case, the Offerer obviously cannot know the RTP Control Protocol (RTCP) transport 
address; thus, it MUST NOT include the "rtcp" attribute [RFC3605]. This avoids potential ICE 
mismatch (see [RFC8839]) for the RTCP transport address. 


If the Offerer wants to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing 
[RFC8858], it still will include the "rtcp-mux" and/or "rctp-mux-only" attribute in the initial Offer. 


In any case, the Offerer MUST include the "ice-options:trickle" attribute in accordance to 
[RFC8838] and MUST include in each "m-" line a "mid" attribute in accordance to [RFC5888]. The 
"mid" attribute identifies the "m-" line to which a candidate belongs and helps in case of multiple 
"m-" lines, when candidate gathering could occur in an order different from the order of the 
"m-" lines. 


4.1.2. Receiving the Initial Offer 


If the initial Offer included candidates, the Answerer uses these candidates to start ICE 
processing as specified in [RFC8838]. 


If the initial Offer included the "ice-options:trickle" attribute, the Answerer MUST be prepared for 
receiving trickled candidates later on. 
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In case of a "m/c-" line with default values, none of the eventually trickled candidates will match 
the default destination. This situation MUST NOT cause an ICE mismatch (see [RFC8839]). 


4.1.3. Sending the Initial Answer 


If the Answerer includes candidates in its initial Answer, it MUST encode these candidates as 
specified in [RFC8839]. 


If the Answerer wants to send its initial Answer before knowing any candidate for one or more 
media descriptions, it MUST set the port to the default value '9' for these media descriptions. If 
the Answerer does not want to include the host IP address in the corresponding "c="line, e.g., due 
to privacy reasons, it SHOULD include a default address in the "c="line, which is set to the IPv4 
address 0.0.0.0 or to the IPv6 equivalent ::. 


In this case, the Answerer obviously cannot know the RTCP transport address; thus, it MUST NOT 
include the "rtcp" attribute [RFC6086]. This avoids potential ICE mismatch (see [RFC8839]) for the 
RTCP transport address. 


If the Answerer accepts the use of RTCP multiplexing [RFC5761] and/or exclusive RTCP 
multiplexing [RFC8858], it will include the "rtcp-mux" attribute in the initial Answer. 


In any case, the Answerer MUST include the "ice-options:trickle" attribute in accordance to 
[RFC8838] and MUST include in each "m=" line a "mid" attribute in accordance to [RFC5888]. 


4.1.4. Receiving the Initial Answer 


If the initial Answer included candidates, the Offerer uses these candidates to start ICE 
processing as specified in [RFC8838]. 


In case of a "m/c=" line with default values, none of the eventually trickled candidates will match 
the default destination. This situation MUST NOT cause an ICE mismatch (see [RFC8839]). 


4.2. Subsequent Offer/Answer Exchanges 


Subsequent Offer/Answer exchanges are handled the same as regular ICE (see Section 4.4 of 
[RFC8839]). 


If an Offer or Answer needs to be sent while the ICE Agents are in the middle of trickling, Section 
4.4 of [RFC8839] applies. This means that an ICE Agent includes candidate attributes for all local 
candidates it had trickled previously for a specific media stream. 


4.3. Establishing the Dialog 


In order to be able to start trickling, the following two conditions need to be satisfied at the SIP 
UAs: 


* Trickle ICE support at the peer agent MUST be confirmed. 
* A dialog MUST have been created between the peers. 
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Section 5 discusses in detail the various options for satisfying the first of the above conditions. 
However, regardless of those mechanisms, agents are certain to have a clear understanding of 
whether their peers support trickle ICE once an Offer and an Answer have been exchanged, 
which also allows for ICE processing to commence (see Figure 3). 


4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery 


Alice Bob 


| 
| INVITE (Offer) | 


|Alice and Bob know that both can trickle| 
|and know that the dialog is in the early| 
|state. Send INFO! | 


Note: "SRFLX" denotes server-reflexive candidates 
Figure 3: A SIP Offerer can freely trickle as soon as it receives an Answer 


As shown in Figure 3, satisfying both conditions is relatively trivial for ICE Agents that have sent 
an Offer in an INVITE and that have received an Answer in a reliable provisional response. It is 
guaranteed to have confirmed support (or lack thereof) for Trickle ICE at the Answerer and to 
have fully initialized the SIP dialog at both ends. Offerers and Answerers (after receipt of the 
PRACK request) in the above situation can therefore freely commence trickling within the newly 
established dialog. 


4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery 


The situation is a bit more delicate for agents that have received an Offer in an INVITE request 
and have sent an Answer in an unreliable provisional response because, once the response has 
been sent, the Answerer does not know when or if it has been received (Figure 4). 
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| 

| 

| 

| |Bob: I don't know if | 
| |Alice got my 183 or if| 
| |her dialog is already | 
| |in the early state. | 
| | Can I send INFO??? | 
| 
| 


Figure 4: A SIP UA that sent an Answer in an unreliable provisional response does not know if it 
was received or if the dialog at the side of the Offerer has entered the early state 


In order to clear this ambiguity as soon as possible, the Answerer needs to retransmit the 
provisional response with the exponential backoff timers described in [RFC3262]. These 
retransmissions MUST cease on receipt of an INFO request carrying a "trickle-ice" Info Package 
body, on receipt of any other in-dialog request from the Offerer, or on transmission of the 
Answer in a 2xx response. The Offerer cannot send in-dialog requests until it receives a response, 
so the arrival of such a request proves that the response has arrived. Using the INFO request for 
dialog confirmation is similar to the procedure described in Section 7.1.1 of [RFC8839], except 
that the STUN binding request is replaced by the INFO request. 


The Offerer MUST send a Trickle ICE INFO request as soon as it receives an SDP Answer in an 
unreliable provisional response. This INFO request MUST repeat the candidates that were 
already provided in the Offer (as would be the case when Half Trickle is performed or when new 
candidates have not been learned since then). The first case could happen when Half Trickle is 
used and all candidates are already in the initial offer. The second case could happen when Full 
Trickle is used and the Offerer is currently gathering additional candidates but did not yet get 
them. Also, if the initial Offer did not contain any candidates, depending on how the Offerer 
gathers its candidates and how long it takes to do so, this INFO could still contain no candidates. 


When Full Trickle is used and if newly learned candidates are available, the Offerer SHOULD also 
deliver these candidates in said INFO request, unless it wants to hold back some candidates in 
reserve, e.g., in case these candidates are expensive to use and would only be trickled if all other 
candidates failed. 


The Offerer SHOULD include an "end-of-candidates" attribute in case candidate discovery has 
ended in the meantime and no further candidates are to be trickled. 


As soon as an Answerer has received such an INFO request, the Answerer has an indication that 
a dialog is established at both ends and trickling can begin (Figure 5). 
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Note: The "+SRFLX" in Figure 5 indicates that additional newly learned server-reflexive 
candidates are included. 


|Bob: Now I know Alice| 
| is ready. Send INFO! | 


| 
| 
| 
| 
| INFO/OK (+SRFLX Cand.) | 
| 
| 
| 
| 


Note: "SRFLX" denotes server-reflexive candidates 


Figure 5: A SIP UA that received an INFO request after sending an unreliable provisional response 
knows that the dialog at the side of the receiver has entered the early state 


When sending the Answer in the 200 OK response to the INVITE request, the Answerer needs to 
repeat exactly the same Answer that was previously sent in the unreliable provisional response 
in order to fulfill the corresponding requirements in [RFC3264]. Thus, the Offerer needs to be 
prepared for receiving a different number of candidates in that repeated Answer than previously 
exchanged via trickling and MUST ignore the candidate information in that 200 OK response. 


4.3.3. Initiating Trickle ICE without an SDP Answer 


The ability to convey arbitrary candidates in INFO message bodies allows ICE Agents to initiate 
trickling without actually sending an Answer. Trickle ICE Agents can therefore respond to an 
INVITE request with provisional responses without an SDP Answer [RFC3261]. Such provisional 
responses serve for establishing an early dialog. 


Agents that choose to establish the dialog in this way MUST retransmit these responses with the 
exponential backoff timers described in [RFC3262]. These retransmissions MUST cease on receipt 
of an INFO request carrying a "trickle-ice" Info Package body, on receipt of any in-dialog requests 
from the Offerer, or on transmission of the Answer in a 2xx response. The Offerer cannot send 
in-dialog requests until it receives a response, so the arrival of such a request proves that the 
response has arrived. This is again similar to the procedure described in Section 6.1.1 of 
[RFC8839], except that an Answer is not yet provided. 


Note: The "+SRFLX" in Figure 6 indicates that additional newly learned server-reflexive 
candidates are included. 
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|Bob: Now I know again | 
| that Alice is ready. | 
| Send INFO! l 


| 
| 
| 
| 
| 
| 
| 
locui gcns d LRQ DE | 
| 
| 
| 
| 
| 
| 


Note: "SRFLX" denotes server-reflexive candidates 


Figure 6: A SIP UA sends an unreliable provisional response without an Answer for establishing an 
early dialog 


When sending the Answer, the agent MUST repeat all currently known and used candidates, if 
any, and MAY include all newly gathered candidates since the last INFO request was sent. 
However, if that Answer was already sent in an unreliable provisional response, the Answerers 
MUST repeat exactly the same Answer in the 200 OK response to the INVITE request in order to 
fulfill the corresponding requirements in [RFC3264]. In case that trickling continued, an Offerer 
needs to be prepared for receiving fewer candidates in that repeated Answer than previously 
exchanged via trickling and MUST ignore the candidate information in that 200 OK response. 


4.4. Delivering Candidates in INFO Requests 


Whenever new ICE candidates become available for sending, agents encode them in "candidate" 
attributes as described by [RFC8839]. For example: 


a-candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host 


The use of SIP INFO requests happens within the context of the Info Package as defined in 
Section 10. The media type [RFC6838] for their payload MUST be set to "application/trickle-ice- 
sdpfrag" as defined in Section 9. The INFO request body adheres to the grammar as specified in 
Section 9.2. 
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Since neither the "candidate" nor the "end-of-candidates" attributes contain information that 
would allow correlating them to a specific "m=" line, it is handled through the use of pseudo "m=" 
lines. 


Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in [RFC4566] and are linked to 
the corresponding "m=" line in the SDP Offer or Answer via the identification tag in a "mid" 
attribute [RFC5888]. A pseudo "m-" line does not provide semantics other than indicating to 
which "m-" line a candidate belongs. Consequently, the receiving agent MUST ignore any 
remaining content of the pseudo "m=" line, which is not defined in this document. This 
guarantees that the "application/trickle-ice-sdpfrag" bodies do not interfere with the Offer/ 
Answer procedures as specified in [RFC3264]. 


When sending the INFO request, the agent MAY, if already known to the agent, include the same 
content into the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer. 
However, since Trickle ICE might be decoupled from the Offer/Answer negotiation, the content 
might be unknown to the agent. In this case, the agent MUST include the following default values: 


* The media field is set to 'audio'. 

* The port value is set to '9'. 

* The proto value is set to 'RTP/AVP'. 

* The fmt field MUST appear only once and is set to 'O'. 


Agents MUST include a pseudo "m=" line and an identification tag in a "mid" attribute for every 
"m-" line whose candidate list they intend to update. Such "mid" attributes MUST immediately 
precede the list of candidates for that specific "m-" line. 


All "candidate" or "end-of-candidates" attributes following a "mid" attribute, up until (and 
excluding) the next occurrence of a pseudo "m-" line, pertain to the "m-" line identified by that 
identification tag. 


Note, that there is no requirement that the INFO request body contains as many pseudo "m=" 
lines as the Offer/Answer contains "m=" lines, nor that the pseudo "m=" lines be in the same 
order as the "m-" lines that they pertain to. The correspondence can be made via the "mid" 
attributes since candidates are grouped in sections headed by "pseudo" "m=" lines. These sections 
contain "mid" attribute values that point back to the true "m-" line. 


An "end-of-candidates" attribute, preceding the first pseudo "m=" line, indicates the end of all 
trickling from that agent, as opposed to end of trickling for a specific "m-" line, which would be 
indicated by a media-level "end-of-candidates" attribute. 


Refer to Figure 7 for an example of the INFO request content. 


The use of pseudo "m-" lines allows for a structure similar to the one in SDP Offers and Answers 
where separate media-level and session-level sections can be distinguished. In the current case, 
lines preceding the first pseudo "m=" line are considered to be session level. Lines appearing in 
between or after pseudo "m=" lines will be interpreted as media level. 
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Note that while this specification uses the "mid" attribute from [RFC5888], it does 
not define any grouping semantics. 


All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes that allow mapping them 
to a specific ICE generation. An agent MUST discard any received INFO requests containing "ice- 
pwd" and "ice-ufrag" attributes that do not match those of the current ICE Negotiation Session. 


The "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as the ones in the Offer/ 
Answer exchange. In other words, if they were present as session-level attributes, they will also 
appear at the beginning of all INFO request payloads, i.e., preceding the first pseudo "m-" line. If 
they were originally exchanged as media-level attributes, potentially overriding session-level 
values, then they will also be included in INFO request payloads following the corresponding 
pseudo "m-" lines. 


Note that when candidates are trickled, [RFC8838] requires that each candidate must be 
delivered to the receiving Trickle ICE implementation not more than once and in the same order 
as it was conveyed. If the signaling protocol provides any candidate retransmissions, they need 
to be hidden from the ICE implementation. This requirement is fulfilled as follows. 


Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer, it MUST 
include all currently known and used local candidates in every INFO request. That is, the agent 
MUST repeat in the INFO request body all candidates that were previously sent under the same 
combination of "ice-pwd" and "ice-ufrag" in the same order as they were sent before. In other 
words, the sequence of a previously sent list of candidates MUST NOT change in subsequent INFO 
requests, and newly gathered candidates MUST be added at the end of that list. Although 
repeating all candidates creates some overhead, it also allows easier handling of problems that 
could arise from unreliable transports like, e.g., loss of messages and reordering, which can be 
detected through the CSeq: header field in the INFO request. 


In addition, an ICE Agent needs to adhere to Section 17 of [RFC8838] on preserving candidate 
order while trickling. 


When receiving INFO requests carrying any candidates, agents MUST first identify and discard 
the attribute lines containing candidates they have already received in previous INFO requests 
or in the Offer/Answer exchange preceding them. 


Such candidates are considered to be equal if their IP address port, transport, and component ID 
are the same. After identifying and discarding the known candidates, the agents MUST forward 
the actual new candidates to the ICE Agents in the same order as they were received in the INFO 
request body. The ICE Agents will then process the new candidates according to the rules 
described in [RFC8838]. 


Receiving an "end-of-candidates" attribute in an INFO request body -- with the "ice-ufrag" and 
"ice-pwd" attributes matching the current ICE generation -- is an indication from the peer agent 
that it will not send any further candidates. When included at the session level, i.e., before any 
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pseudo "m-" line, this indication applies to the whole session; when included at the media level, 
the indication applies only to the corresponding "m=" line. Handling of such end-of-candidates 
indications is defined in [RFC8838]. 


The example in Figure 7 shows the content of a candidate delivering INFO request. In the 
example, the "end-of-candidates" attributes indicate that the candidate gathering is finished and 
that no further INFO requests follow. 


INFO sip:alice@example.com SIP/2.0 


Info-Package: trickle-ice 

Content-type: application/trickle-ice-sdpfrag 
Content-Disposition: Info-Package 
Content-length: 862 


a-ice-pwd:asd88fgpdd777uzjYhagZg 
a-ice-ufrag:8hhY 
m-audio 9 RTP/AVP 0 
a=mid:1 
a-candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host 
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host 
a-candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host 
a-candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host 
a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx 

raddr 192.0.2.1 rport 8998 
a-candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx 

raddr 192.0.2.1 rport 8998 
a=end-of-candidates 
m=audio 9 RTP/AVP @ 
a-mid:2 
a-candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host 
a-candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host 
a-candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host 
a-candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host 
a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx 

raddr 192.0.2.1 rport 9998 
a-candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx 

raddr 192.0.2.1 rport 9998 
a=end-of-candidates 


Note: In a real INFO request, there will be no line breaks 
in the "candidate" attributes 


Figure 7: An Example for the Content of an INFO Request 


5. Initial Discovery of Trickle ICE Support 


SIP UAs are required by [RFC8838] to indicate their support of and intent to use Trickle ICE in 
their Offers and Answers by using the "ice-options:trickle" attribute, and they MUST include the 
SIP option-tag "trickle-ice" in a SIP Supported: or Require: header field. This makes discovery 
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fairly straightforward for Answerers or for cases where Offers need to be generated within 
existing dialogs (i.e., when sending UPDATE or re-INVITE requests). In both scenarios, prior SDP 
bodies will have provided the necessary information. 


Obviously, such information is not available at the time a first Offer is being constructed, and it is 
therefore impossible for ICE Agents to determine support for incremental provisioning that way. 
The following options are suggested as ways of addressing this issue. 


5.1. Provisioning Support for Trickle ICE 


In certain situations, it may be possible for integrators deploying Trickle ICE to know in advance 
that some or all endpoints reachable from within the deployment will support Trickle ICE. This is 
the case, for example, if Session Border Controllers (SBCs) with support for this specification are 
used to connect to UAs that do not support Trickle ICE. 


While the exact mechanism for allowing such provisioning is out of scope here, this specification 
encourages trickle ICE implementations to allow the option in the way they find most 
appropriate. 


However, an Offerer assuming Trickle ICE support MUST include a SIP Require: trickle-ice header 
field. That way, if the provisioned assumption of Trickle ICE support ends up being incorrect, the 
failure is (a) operationally easy to track down and (b) recoverable by the client, i.e., they can 
resend the request without the SIP Require: header field and without the assumption of Trickle 
ICE support. 


5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUUs) 


[RFC3840] provides a way for SIP UAs to query for support of specific capabilities using, among 
others, OPTIONS requests. On the other hand, support for GRUU according to [RFC5627] allows 
SIP requests to be addressed to specific UAs (as opposed to arbitrary instances of an address of 
record). Combining the two and using the "trickle-ice" option tag defined in Section 10.6 provides 
SIP UAs with a way of learning the capabilities of specific SIP UA instances and then addressing 
them directly with INVITE requests that require Trickle ICE support. 


Such learning of capabilities may happen in different ways. One option for a SIP UA is to learn 
the GRUU instance ID of a peer through presence and then to query its capabilities with an 
OPTIONS request. Alternatively, it can also just send an OPTIONS request to the Address of 
Record (AOR) it intends to contact and then inspect the returned response(s) for support of both 
GRUU and Trickle ICE (Figure 8). It is noted that using the GRUU means that the INVITE request 
can go only to that particular device. This prevents the use of forking for that request. 
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200 OK 
Contact: sip:b1@example.com;gr=hha9s8d-999a 
;audio;video|;trickle-ice;... 


INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 
Supported: trickle-ice | 

(Offer) | 

| cu | 
| 

| 


Figure 8: Trickle ICE Support Discovery with OPTIONS and GRUU 


January 2021 


Confirming support for Trickle ICE through [RFC3840] gives SIP UAs the option to engage in Full 
Trickle negotiation (as opposed to the more lengthy Half Trickle) from the very first Offer they 


send. 


5.3. Fall Back to Half Trickle 


In cases where none of the other mechanisms in this section are acceptable, SIP UAs should use 
the Half Trickle mode defined in [RFC8838]. With Half Trickle, agents initiate sessions the same 
way they would when using ICE for SIP [RFC8839]. This means that, prior to actually sending an 
Offer, agents first gather ICE candidates in a blocking way and then send them all in that Offer. 
The blocking nature of the process implies that some amount of latency will be accumulated, and 
it is advised that agents try to anticipate it where possible, for example, when user actions 
indicate a high likelihood for an imminent call (e.g., activity on a keypad or a phone going off 


hook). 


Using Half Trickle results in Offers that are compatible with both ICE SIP endpoints [RFC8839] 
and legacy endpoints [RFC3264]. 
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STUN/TURN STUN/TURN 
Servers Alice Bob Servers 
| | | 
ec | | 
| | 
| | 
| Candidate | 
| | 
| | 
| Discovery | 
| | 
| | 
| 


| 
INFO (more candidates) | Candidate 


<SSSSSSS5SS5 5555 5555555555555 | Discovery 


<SSSSS555SS5 5555 5555555555555 | 
| | 
200 OK | | 
Pat ee | | 
D 4.31 —31—31—1—1—1 MEDIA FLOWS =======> | 
| 


Figure 9: Example of a Typical (Half) Trickle ICE Exchange with SIP 


As a reminder, once a single Offer or Answer has been exchanged within a specific dialog, 
support for Trickle ICE will have been determined. No further use of Half Trickle will therefore 
be necessary within that same dialog, and all subsequent exchanges can use the Full Trickle 
mode of operation. 


6. Considerations for RTP and RTCP Multiplexing 


The following consideration describes options for Trickle ICE in order to give some guidance to 
implementers on how trickling can be optimized with respect to providing RTCP candidates. 


Handling of the "rtcp" attribute [RFC3605] and the "rtcp-mux" attribute for RTP/RTCP 
multiplexing [RFC5761] is already considered in Section 5.1.1.1 of [RFC8445] and in [RFC5761]. 
These considerations are still valid for Trickle ICE; however, trickling provides more flexibility 
for the sequence of candidate exchange in case of RTCP multiplexing. 
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If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [RFC8858], the 
procedures in that document apply for the handling of the "rtcp-mux-only", "rtcp", and "rtcp- 
mux" attributes. 


While a Half Trickle Offerer has to send an Offer compliant to [RFC8839] and [RFC5761] including 
candidates for all components, the flexibility of a Full Trickle Offerer allows the sending of only 
RTP candidates (component 1) in the initial Offer assuming that RTCP multiplexing is supported 
by the Answerer. A Full Trickle Offerer would need to start gathering and trickling RTCP 
candidates (component 2) only after having received an indication in the Answer that the 
Answerer unexpectedly does not support RTCP multiplexing. 


A Trickle Answerer MAY include an "rtcp-mux" attribute [RFC5761] in the "application/trickle-ice- 
sdpfrag" body if it supports and uses RTP and RTCP multiplexing. The Trickle Answerer needs to 
follow the guidance on the usage of the "rtcp" attribute as given in [RFC8839] and [RFC3605]. 
Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the 
Answerer supports and uses RTP and RTCP multiplexing. The Offerer can use this information, 
e.g., for stopping the gathering of RTCP candidates and/or for freeing corresponding resources. 


This behavior is illustrated by the following example Offer that indicates support for RTP and 
RTCP multiplexing. 


-0 
-alice 2890844526 2890844526 IN IP6 atlanta.example.com 

C-IN IP6 2001:db8:a0b:12f0: :3 

t-0 0 

a-ice-pwd:777uzjYhagZgasd88fgpdd 

a-ice-ufrag:Yhh8 

m-audio 5000 RTP/AVP 0 

a=mid:1 

a=rtcp-mux 

a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 


Once the dialog is established as described in Section 4.3, the Answerer sends the following INFO 
request. 


INFO sip:alice@example.com SIP/2.0 


Info-Package: trickle-ice 

Content-type: application/trickle-ice-sdpfrag 
Content-Disposition: Info-Package 
Content-length: 161 


a-ice-pwd:asd88fgpdd777uzjYhagZg 

a-ice-ufrag:8hhY 

m-audio 9 RTP/AVP 0 

a=mid:1 

a=rtcp-mux 

a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host 
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This INFO request indicates that the Answerer supports and uses RTP and RTCP multiplexing as 
well. It allows the Offerer to omit gathering RTCP candidates or releasing already gathered RTCP 
candidates. If the INFO request did not contain the "rtcp-mux" attribute, the Offerer has to gather 
RTCP candidates unless it wants to wait until receipt of an Answer that eventually confirms 
support or non-support for RTP and RTCP multiplexing. In case the Offerer already sent RTCP 
candidates in a previous INFO request, it still needs to repeat them in subsequent INFO requests, 
even when that support for RTCP multiplexing was confirmed by the Answerer and the Offerer 
has released its RTCP candidates. 


7. Considerations for Media Multiplexing 


The following considerations describe options for Trickle ICE in order to give some guidance to 
implementers on how trickling can be optimized with respect to providing candidates in case of 
Media Multiplexing [RFC8843]. It is assumed that the reader is familiar with [RFC8843]. 


ICE candidate exchange is already considered in Section 10 of [RFC8843]. These considerations 
are still valid for Trickle ICE; however, trickling provides more flexibility for the sequence of 
candidate exchange, especially in Full Trickle mode. 


Except for bundle-only "m-" lines, a Half Trickle Offerer has to send an Offer with candidates for 
all bundled "m-" lines. The additional flexibility, however, allows a Full Trickle Offerer to 
initially send only candidates for the "m=" line with the suggested Offerer BUNDLE address. 


On receipt of the Answer, the Offerer will detect if BUNDLE is supported by the Answerer and if 
the suggested Offerer BUNDLE address was selected. In this case, the Offerer does not need to 
trickle further candidates for the remaining "m=" lines in a bundle. However, if BUNDLE is not 
supported, the Full Trickle Offerer needs to gather and trickle candidates for the remaining "m-" 
lines as necessary. If the Answerer selects an Offerer BUNDLE address that is different from the 
suggested Offerer BUNDLE address, the Full Trickle Offerer needs to gather and trickle 
candidates for the "m-" line that carries the selected Offerer BUNDLE address. 


A Trickle Answerer SHOULD include a "group:BUNDLE" attribute [RFC8843] at session level in the 
"application/trickle-ice-sdpfrag" body if it supports and uses bundling. When doing so, the 
Answerer MUST include all identification-tags in the same order that is used or will be used in the 
Answer. 


Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the 
Answerer supports and uses bundling. The Offerer can use this information, e.g., for stopping the 
gathering of candidates for the remaining "m=" lines in a bundle and/or for freeing 
corresponding resources. 


This behavior is illustrated by the following example Offer that indicates support for Media 
Multiplexing. 
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If the Offerer already sent candidates for "m-" lines in a bundle in a previous INFO request, it 
still needs to repeat them in subsequent INFO requests, even when that support for bundling was 
confirmed by the Answerer and the Offerer has released candidates that are no longer needed. 


lice 2890844526 2890844526 IN IP6 atlanta.example.com 


C-IN IP6 2001:db8:a0b:12f0::3 

t-0 0 

a-group:BUNDLE foo bar 
a-ice-pwd:777uzjYhagZgasd88fgpdd 
a-ice-ufrag:Yhh8 

m-audio 10000 RTP/AVP 0 

a-mid:foo 

a-rtcp-mux 

a-rtpmap:0 PCMU/8000 

a=extmap 1 urn:ietf:params:rtp-hdrext:sdes :mid 
a-candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host 
m-video 10002 RTP/AVP 31 

a-mid:bar 

a-rtcp-mux 

a-rtpmap:31 H261/90000 

a=extmap 1 urn:ietf:params:rtp-hdrext:sdes :mid 


The example Offer indicates support for RTP and RTCP multiplexing and contains a "candidate" 
attribute only for the "m-" line with the suggested Offerer BUNDLE address. Once the dialog is 
established as described in Section 4.3, the Answerer sends the following INFO request. 


INFO sip:alice@example.com SIP/2.0 


Info-Package: trickle-ice 

Content-type: application/trickle-ice-sdpfrag 
Content-Disposition: Info-Package 
Content-length: 219 


a-group:BUNDLE foo bar 

a-ice-pwd:asd88fgpdd777uzjYhagZg 

a-ice-ufrag:8hhY 

m-audio 9 RTP/AVP 0 

a=mid:foo 

a=rtcp-mux 

a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 


This INFO request indicates that the Answerer supports and uses Media Multiplexing as well. 
Note that the Answerer only includes a single pseudo "m=" line since candidates matching those 
from the second "m=" line in the offer are not needed from the Answerer. 


The INFO request also indicates that the Answerer accepted the suggested Offerer BUNDLE 
address. This allows the Offerer to omit gathering RTP and RTCP candidates for the other "m=" 
lines or releasing already gathered candidates. If the INFO request did not contain the 
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"group:BUNDLE'" attribute, the Offerer has to gather RTP and RTCP candidates for the other "m=" 
lines unless it wants to wait until receipt of an Answer that eventually confirms support or non- 
support for Media Multiplexing. 


Independent of using Full Trickle or Half Trickle mode, the rules from [RFC8859] apply to both, 
Offerer and Answerer, when putting attributes as specified in Section 9.2 in the "application/ 
trickle-ice-sdpfrag" body. 


8. SDP "end-of-candidates" Attribute 


8.1. Definition 


This section defines the new SDP media-level and session-level [RFC4566] "end-of-candidates" 
attribute. "end-of-candidates" is a property attribute [RFC4566]; hence, it has no value. By 
including this attribute in an Offer or Answer, the sending agent indicates that it will not trickle 
further candidates. When included at the session level, this indication applies to the whole 
session; when included at the media level, the indication applies only to the corresponding 
media description. 


Name: end-of-candidates 

Value: N/A 

Usage Level: media and session level 
Charset Dependent: no 

Mux Category: IDENTICAL 


Example: a-end-of-candidates 


8.2. Offer/Answer Procedures 


The Offerer or Answerer MAY include an "end-of-candidates" attribute in case candidate 
discovery has ended and no further candidates are to be trickled. The Offerer or Answerer MUST 
provide the "end-of-candidates" attribute together with the "ice-ufrag" and "ice-pwd" attributes of 
the current ICE generation as required by [RFC8838]. When included at the session level, this 
indication applies to the whole session; when included at the media level, the indication applies 
only to the corresponding media description. 


Receipt of an "end-of-candidates" attribute at an Offerer or Answerer -- with the "ice-ufrag" and 
"ice-pwd" attributes matching the current ICE generation -- indicates that the gathering of 
candidates has ended at the peer, for either the session or only the corresponding media 
description as specified above. The receiving agent forwards an end-of-candidates indication to 
the ICE Agent, which in turn acts as specified in [RFC8838]. 
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9. Content Type "application/trickle-ice-sdpfrag" 


9.1. Overall Description 


An "application/trickle-ice-sdpfrag" body is used exclusively by the "trickle-ice" Info Package. 
Other SDP-related applications need to define their own media type. The INFO request body uses 
a subset of the possible SDP lines as defined by the grammar in [RFC4566]. A valid body uses only 
pseudo "m-" lines and certain attributes that are needed and/or useful for trickling candidates. 
The content adheres to the following grammar. 


9.2. Grammar 


The grammar of an "application/trickle-ice-sdpfrag" body is based on the following ABNF 
[RFC5234]. It specifies the subset of existing SDP attributes that is needed or useful for trickling 
candidates. The grammar uses the indicator for case-sensitive 96s, as defined in [RFC7405], but it 
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also imports grammar for other SDP attributes that precede the production of [RFC7405]. A 
sender SHOULD use lower case for attributes from such earlier grammar, but a receiver MUST 


treat them as case insensitive. 


; Syntax 

trickle-ice-sdpfrag session-level-fiel 
pseudo-media-description 

session-level-fields = *(session-level-fie 


session-level-field = ice-lite-attribute 
ice-pwd-attribute / 
ice-ufrag-attribute / 
ice-options-attribute / 
ice-pacing-attribute / 
end-of-candidates-attrib 
bundle-group-attribute / 


extension-attribute-fiel 
"Af o 
ice-lite-attribute = %s"a" "=" ice-lit 
ice-pwd-attribute = %s"a" "=" ice-pwd 
ice-ufrag-attribute = %s"a" "=" ice-ufr 
ice-pacing-attribute = %s"a" "=" ice-pac 
ice-options-attribute = %s"a" "=" ice-opt 
end-of-candidates-attribute = %s"a" "=" e 
end-of-candidates = %s"end-of-c 
bundle-group-attribute = %s"a" "=" %s"grou 
*(SP identifica 

bundle-semantics = "BUNDLE" 


extension-attribute-fields attribute-f 


*( media-f 
trickle-ice-att 
trickle-ice-attribute-fields - *(trickle-i 
trickle-ice-attribute-field mid-attribut 
candidate-attribut 

ice-pwd-attribute 
ice-ufrag-attribut 
remote-candidate-a 
end-of-candidates- 

rtcp-attribute / 
rtcp-mux-attribute 
rtcp-mux-only-attr 
extension-attribut 


pseudo-media-descriptions 


rtcp-attribute E WES. WEE 
rtcp-mux-attribute —NRooca da Eo 
rtcp-mux-only-attribute = $s'"a' "=" 
candidate-attributes Suc ae — a 
remote-candidate-attribute e Was es UEM 


ds 
S 
ld CRLF) 


if 


ute / 


ds 
r future extensions 


e 
-att 

ag-att 

ing-att 

ions 
nd-of-candidates 
andidates" 

p:" bundle-semantics 
tion-tag) 


ields 


ield 
ribute-fields ) 
ce-attribute-field CRLF) 
e / 
es / 
j/ 
e / 
ttribute / 
attribute / 


/ 
ibute / 
e-fields 
for future extensions 


*s"rtcp" 
*s"rtcp-mux" 
*s"rtcp-mux-only" 
candidate-attribute 
remote-candidate-att 


ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att, ice-options, candidate- 


attribute, and remote-candidate-att are from [RFC8839]; 


identification-tag and mid-attribute are 


from [RFC5888]; and media-field and attribute-fields are from [RFC4566]. The "rtcp" attribute is 
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defined in [RFC3605], the "rtcp-mux" attribute is defined in [RFC5761], and the "rtcp-mux-only" 
attribute is defined in [RFC8858]. The latter attributes lack formal grammar in their 
corresponding RFCs and are reproduced here. 


The "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as the ones in the Offer/ 
Answer exchange. In other words, if they were present as session-level attributes, they will also 
appear at the beginning of all INFO request payloads, i.e., preceding all pseudo "m=" lines. If they 
were originally exchanged as media-level attributes, potentially overriding session-level values, 
then they will also be included in INFO request payloads following the corresponding pseudo 
"m-" lines. 


An Agent MUST ignore any received unknown extension-attribute-fields. 


10. Info Package 


10.1. Rationale -- Why INFO? 


The decision to use SIP INFO requests as a candidate transport method is based primarily on 
their lightweight nature. Once a dialog has been established, INFO requests can be exchanged 
both ways with no restrictions on timing and frequency and no risk of collision. 


A critical fact is that the sending of Trickle ICE candidates in one direction is entirely uncoupled 
from sending candidates in the other direction. Thus, the sending of candidates in each direction 
can be done by a stream of INFO requests that is not correlated with the stream of INFO requests 
in the other direction. And since each INFO request cumulatively includes the contents of all 
previous INFO requests in that direction, the ordering between INFO requests need not be 
preserved. All of this permits using largely independent INFO requests. 


Contrarily, UPDATE or other Offer/Answer mechanisms assume that the messages in each 
direction are tightly coupled with messages in the other direction. Using Offer/Answer and 
UPDATE requests [RFC3311] would introduce the following complications: 


Blocking of messages: Offer/Answer is defined as a strictly sequential mechanism in [RFC3264]. 
There can only be a maximum of one active exchange at any point of time. Both sides cannot 
simultaneously send Offers nor can they generate multiple Offers prior to receiving an 
Answer. Using UPDATE requests for candidate transport would therefore imply the 
implementation of a candidate pool at every agent where candidates can be stored until it is 
once again that agent's "turn" to emit an Answer or a new Offer. Such an approach would 
introduce non-negligible complexity for no additional value. 


Elevated risk of glare: The sequential nature of Offer/Answer also makes it impossible for both 
sides to send Offers simultaneously. What's worse is that there are no mechanisms in SIP to 
actually prevent that. [RFC3261], where the situation of Offers crossing on the wire is 
described as "glare", only defines a procedure for addressing the issue after it has occurred. 
According to that procedure, both Offers are invalidated and both sides need to retry the 
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negotiation after a period between 0 and 4 seconds. The high likelihood for glare and the 
average two-second backoff intervals to occur implies that the duration of Trickle ICE 
processing would not only fail to improve but actually exceed those of regular ICE. 


INFO messages decouple the exchange of candidates from the Offer/Answer negotiation and are 
subject to none of the glare issues described above, which makes them a very convenient and 
lightweight mechanism for asynchronous delivery of candidates. 


Using in-dialog INFO messages also provides a way of guaranteeing that candidates are delivered 
end to end, between the same entities that are actually in the process of initiating a session. Out- 
of-dialog alternatives would have implied requiring support for GRUU [RFC5627] that, given 
GRUUs relatively low adoption levels, would have constituted too strong of a constraint to the 
adoption of Trickle ICE. 


10.2. Overall Description 


This specification defines an Info Package for use by SIP UAs implementing Trickle ICE. INFO 
requests carry ICE candidates discovered after the peer UAs have confirmed mutual support for 
Trickle ICE. 


10.3. Applicability 


The purpose of the ICE protocol is to establish a media path in the presence of NAT and firewalls. 
The candidates are transported in INFO requests and are part of this establishment. 


Candidates sent by a Trickle ICE Agent after the Offer follow the same signaling path and reach 
the same entity as the Offer itself. While it is true that GRUUs can be used to achieve this, one of 
the goals of this specification is to allow operation of Trickle ICE in as many environments as 
possible including those without GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests 
would not satisfy this goal. 


10.4. Info Package Name 


This document defines a SIP Info Package as per [RFC6086]. The Info Package token name for this 
package is "trickle-ice". 


10.5. Info Package Parameters 


This document does not define any Info Package parameters. 


10.6. SIP Option Tags 
[RFC6086] allows Info Package specifications to define SIP option-tags. This specification extends 
the option-tag construct of the SIP grammar as follows: 


option-tag /- "trickle-ice" 
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SIP entities that support this specification MUST place the "trickle-ice" option-tag in a SIP 
Supported: or Require: header field within all SIP INVITE requests and responses. 


When responding to, or generating, a SIP OPTIONS request, a SIP entity MUST also include the 
"trickle-ice" option-tag in a SIP Supported: or Require: header field. 


10.7. INFO Request Body Parts 


Entities implementing this specification MUST include a payload of type "application/trickle-ice- 
sdpfrag" in SIP INFO requests as defined in Section 9.2. The payload is used to convey SDP- 
encoded ICE candidates. 


10.8. Info Package Usage Restrictions 


This document does not define any Info Package Usage Restrictions. 


10.9. Rate of INFO Requests 


Given that IP addresses may be gathered rapidly, a Trickle ICE Agent with many network 
interfaces might create a high rate of INFO requests if every newly detected candidate is trickled 
individually without aggregation. An implementation MUST aggregate ICE candidates in case an 
unreliable transport protocol such as UDP is used. A Trickle ICE Agent MUST NOT have more than 
one INFO request pending at any one time. When INFO messages are sent over an unreliable 
transport, they are retransmitted according to the rules specified in [RFC3261], Section 17.1.2.1. 


If the INFO requests are sent on top of TCP, which is probably the standard way, it is not an issue 
for the network anymore, but it can remain one for SIP proxies and other intermediaries 
forwarding the SIP INFO messages. Also, an endpoint may not be able to tell that it has 
congestion controlled transport all the way. 


10.10. Info Package Security Considerations 


See Section 13. 


11. Deployment Considerations 


Trickle ICE uses two mechanisms for the exchange of candidate information. This imposes new 
requirements to certain middleboxes that are used in some networks, e.g., for monitoring 
purposes. While the first mechanism, SDP Offers and Answers, is already used by regular ICE and 
is assumed to be supported, the second mechanism, INFO request bodies, needs to be considered 
by such middleboxes as well when trickle ICE is used. Such middleboxes need to make sure that 
they remain in the signaling path of the INFO requests and understand the INFO request body. 
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12. IANA Considerations 


12.1. SDP "end-of-candidates" Attribute 


This section defines a new SDP media-level and session-level [RFC4566] "end-of-candidates" 
attribute, which is a property attribute [RFC4566] and hence has no value. 


Name: end-of-candidates 

Value: N/A 

Usage Level: media and session 

Charset Dependent: no 

Purpose: The sender indicates that it will not trickle further ICE candidates. 


O/A Procedures: RFC 8840 defines the detailed SDP Offer/Answer procedures for the "end- 
of-candidates" attribute. 


Mux Category: IDENTICAL 
Reference: RFC 8840 


Example: a=end-of-candidates 


12.2. Media Type "application/trickle-ice-sdpfrag" 


This document defines the new media type "application/trickle-ice-sdpfrag" in accordance with 
[RFC6838]. 


Typename: application 

Subtype name: trickle-ice-sdpfrag 
Required parameters: None. 
Optional parameters: None. 


Encoding considerations: The media contents follow the same rules as SDP, except as noted in 
this document. The media contents are text, with the grammar specified in Section 9.2. 


Although the initially defined content of a trickle-ice-sdpfrag body does only include ASCII 
characters, UTF-8-encoded content might be introduced via extension attributes. The "charset 
attribute may be used to signal the presence of other character sets in certain parts of a 
trickle-ice-sdpfrag body (see [RFC4566]). Arbitrary binary content cannot be directly 
represented in SDP or a trickle-ice-sdpfrag body. 


Security considerations: See [RFC4566] and RFC 8840 
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Interoperability considerations: See RFC 8840 
Published specification: See RFC 8840 
Applications that use this media type: Trickle ICE 
Fragment identifier considerations: N/A 


Additional information: 


Deprecated alias names for this type: N/A 
Magic number(s): N/A 

File extension(s): N/A 

Macintosh File Type Code(s): N/A 


Person and email address to contact for further information: The IESG (iesg@ietf.org) 
Intended usage: Trickle ICE for SIP as specified in RFC 8840. 

Restrictions on usage: N/A 

Author/Change controller: The IESG (iesg@ietf.org) 


Provisional registration? (standards tree only): N/A 


12.3. SIP Info Package "trickle-ice" 


This document defines a new SIP Info Package named "trickle-ice" and updates the "Info 
Packages Registry" with the following entry. 


Name Reference 


trickle-ice RFC 8840 
Table 1 


12.4. SIP Option Tag "trickle-ice" 


This specification registers a new SIP option tag "trickle-ice" as per the guidelines in Section 27.1 
of [RFC3261] and updates the "Option Tags" subregistry of the SIP Parameters registry with the 
following entry: 


Name Description Reference 


trickle-ice This option tag is used to indicate that a UA supports and RFC 8840 
understands Trickle ICE. 


Table 2 
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13. Security Considerations 


The Security Considerations of [RFC6086], [RFC8838], and [RFC8839] apply. This document 
clarifies how the above specifications are used together for trickling candidates and does not 
create additional security risks. 


The new Info Package "trickle-ice" and the new media type "application/trickle-ice-sdpfrag" do 
not introduce additional security considerations when used in the context of Trickle ICE. Both 
are not intended to be used for other applications, so any security considerations for its use in 
other contexts is out of the scope of this document 
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